The Extensible Messaging and Presence Protocol (XMPP) is an open Extensible Markup Language (XML) protocol for near-real-time messaging, presence, and request-response services. These services are also named as instant messaging services. The core features of the XMPP are defined in the IETF standard RFC 3920. The basic syntax and semantics were developed originally within the Jabber open-source community. Although XMPP is not wedded to any specific network architecture, to date it usually has been implemented via a client-server architecture wherein a client utilizing XMPP accesses a server over a TCP connection, and servers also communicate with each other over TCP connections. Being an open standard, XMPP has got quite attraction in the open source community world wide and numerous free software packages exist implementing XMPP clients and XMPP server on different platforms. Some companies are basing their chat and voice offerings on XMPP specifications. FIG. 1 shows a schematic diagram of a mobile communication network which is connected to a TCP/IP-based network 100, which can be the Internet or any other TCP/IP based network. In this embodiment, three XMPP servers 111, 121, 131 are connected to the Internet 100. Two XMPP clients 112, 122 are associated to two of the XMPP server 111, 121 via a TCP/IP connection. The XMPP clients 112, 122 can e.g. be a personal computer or a laptop which are connected to the internet 100 via a normal dial-connection. The address 113 of the first XMPP client 112 “client1” is “client1@XMPPserver1.domain/device1” wherein the address 123 of the second XMPP client 122 is “client2@XMPPserver2.domain/device2”. In FIG. 1 and in FIG. 4, the addresses 113, 123, 133 are disclosed in a simplified form because the domain indicator and the device indicator are missing for better view. These addresses are in accordance with the standardized XMPP JID (Jabber identity) which is a combination of a user ID, a server ID and a device ID. By these addresses 113, 123, 133 all XMPP clients 112, 122, 132 can be identified and data can be routed via the internet. FIG. 1 further discloses a mobile communication network, wherein only selected components of the mobile communication network are depicted. A mobile terminal or user equipment 18 comprises a XMPP client 132. The XMPP client 132 can be an application which is stored in the UE 18. The XMPP client 132 can be associated to a XMPP server 131 e.g. via a TCP-based connection. The address 133 of the XMPP client 132 is “client3@XMPPserver3.domain/UEdevice”. This connection can be realized by a wireless LAN connection, wherein the UE 18 is associated to a WLAN router 19 which is further connected to the Internet 100. Another possibility is that the UE 18 is connected via the radio network 17 to a packet switched (PS) network or to an evolved packet switched (EPS) network. One setup of a PS network is depicted in FIG. 1 by a Serving GPRS Support Node (SGSN) node 15 and Gateway GPRS Support Node (GGSN) 16 which is linked via an IP based core network connection and via the Internet 100 to the XMPP server 131. The embodiment according FIG. 1 further discloses a connection between the SGSN node 15 of a packet switched network and a mobile switching node 14, which can be a MSC-S node 14 of a circuit switched (CS) network. This link between both nodes, which is called Gs interface, depicts the possibility of transferring data between both networks. A further packet switched network is the Evolved Packet Core (EPC) network, wherein one node is the Mobility Management Entity (MME), which can be linked to the MSC-S via a SGs interface. FIG. 1 does not depict further gateway nodes which might be necessary to implement a connection between a circuit-switched network and a packet switched network.
FIG. 2 shows a block diagram of a prior-art mobile switching node 14, which is in this embodiment a MSC-S node 14, wherein only selected parts are depicted. The MSC-S 14 comprises a GSM call control function 143 which contains mobile traffic coordinators for originating and/or terminating calls and emergency calls. The coordinators are mainly used for call transaction setup, call forwarding, call supervision and call release. It allows also direct and handle calls towards other circuit switched networks. The GSM call control function 143 is linked with the core network interface 145 which hosts the core network interfaces of the MSC-S. The core network interface 145 analyses incoming signalling which is either forwarded to another node in the core network or handled locally and terminated at a radio network interface. For outgoing signalling a routing function 146 is consulted to determine the next destination node and the physical interface to reach it. The core network interface 145 is IP (Internet Protocol) based. The GSM call control function 143 is further connected to a GSM mobility function 142 which allows the mobile terminal to roam between radio location areas and to continue ongoing calls also across radio network borders. One main function is the handover procedure to hand over a mobile terminal from one area to another. The GSM mobility function 142 or mobility management function therefore contains a logic coordinator for mobility, roaming and handover procedures and handles the location updating functions and handover functions. Furthermore the GSM mobility function 142 contains functions for packing or unpacking of signalling messages to the terminal and to the radio network belonging to mobility. Signalling messages can be used e.g. in case of authentication, identification and location updating.
The GSM mobility function 142 is connected to the A-/Iu-interface function 141 which hosts the radio network interface resources of the MSC-S 14.
The MSC-S 14 further comprises a charging function 144 which is connected to the GSM call control function 143 and the core network interface 145. The charging function 144 is a basic function in the MSC-S 14 to collect traffic case related data to be used for offline billing.
The MSC-S 14 further comprises a VLR data storage 147 which stores the subscriber data. The VLR 147 is connected to a home location register 4 (HLR) which is a central database that contains details of each mobile phone subscriber that is authorized to use the core network.
The MSC-S further comprises a GSM authentication component 148 which implements the GSM authentication algorithm. The GSM authentication component 148 is also connected to the HLR 4 to receive and verify authentication data from the central database.
FIG. 3 depicts a block diagram of a well known XMPP server 131. The XMPP server 131 contains a XMPP stanzas router 1311 which is the backbone of the XMPP server 131. The XMPP stanzas router 1311 accepts connections from XMPP server components and passes XML (extended markup language) packets between XMPP server components. A client to server component (c2s) 1312 handles communication with associated XMPP clients. The XMPP stanzas router 1311 is connected to a XMPP session manager 1316. The session manager 1316 implements the bulk of the instant messaging features like message passing, presence, roster and subscription. The session manager 1316 is connected to data storage in order to provide persistent data storage. The associated data storage is not depicted in FIG. 3. It could be located outside the XMPP server 131 or it could be part of the XMPP server 131. Additionally the session manager 1316 handles the XMPP extensions of service discovery and privacy lists. A c2s component 1312 is connected to the XMPP stanzas router 1311 and is e.g. responsible for connecting XMPP clients 112, 122, 132 to the XMPP server 131, passing communication packets to a session manager 1316 of the XMPP server 131, authenticating XMPP clients 112, 122, 132, registering users and triggers activity with the session manager 1316. A server to server (s2s) component 1315 is connected to the XMPP stanzas router 1311 and handles communications with external XMPP servers by passing communication packets between other internal components and external servers. The s2s component 1315 further performs dial-back function to authenticate remote XMPP servers. A multi user chat (muc) 1314 is connected to the XMPP stanzas router 1311 to implement support for chat rooms. A publish subscribe component (pubsub) 1313 implements a generic functionality for providing presence. The pubsub component 1313 is connected to the Stanzas router 1311. The XMPP server 131 is connected via a TCP/IP connection to the Internet 100 such that it possible to reach this server from any other device connected to the Internet 100. The s2s component 1315 and the c2s component 1312 communicate via the Internet 100 with external clients 112, 122, 132 and external server 111, 121.
A XMPP extension named Jingle is defined in the XMPP standards to realize a Voice over IP session between XMPP clients. It is therefore possible to exchange media data like Voice or Video data between XMPP clients. The XMPP clients who might be integrated in mobile terminals can therefore take over the functionality of normal voice clients in a mobile terminal. A Voice over IP communication based on the XMPP protocol is today only possible between clients using XMPP. If an originating CS mobile subscriber wants to establish a call to a destination CS mobile subscriber with an integrated XMPP client, the terminating CS call fails if the destination CS mobile subscriber is not reachable even if the destination CS mobile subscriber is reachable over a XMPP connection.
One further problem of a client to client connection between two XMPP client, controlled by a XMPP server, is that if one client is located in a private Local Area Network (LAN) which is protected via a firewall against the public Internet, a Network Address Translation (NAT) could be performed. The NAT translates requests from within the LAN using private IP addresses to requests towards the Internet using a public IP address. This public IP address is received from the Internet Service Provider (ISP) at attach, e.g. at DSL line activation. Without knowledge of the public IP address, the XMPP Voice over IP (VoIP) clients has nothing to offer in the user plane establishment signalling. Technologies to circumvent this problem is a Session Traversal Utilities for NAT (STUN) which allows a client to ask the NAT firewall about public IP address and opening of pin-holes in the firewall for user plane connections. However, very few NAT firewalls today support STUN. Furthermore, due to the related security threat when opening holes in the firewall, STUN is actively disabled in many networks. So practically XMPP clients with VoIP features fail to establish user plane behind firewalls.